The idea that I termed as Omnipresent Operating System is to share application sessions (along with all the state/session data etc.) from one system to another system that allows to continue the application running on the later system in exactly in the same state and using the same session without the user to start the application from beginning or using a different application session in the later system to use all the benefits of available in the later system. This helps to achieve unified, seamless & omnipresence-experience across different systems.
100 and 200 are two devices connected over the same network via wifi/Lan/Bluetooth etc. (e.g. 150 & 250). 110 is an application running in 100. 120 is the Runtime Component that helps to achieve the desired outcome proposed in the invention (might be part of the OS). 100 is connected to internet via port 140. 111 is the session data, 112 is user authentication and related data, 113 is environment related data (e.g. browser version, OS version, history, some system variable etc. ), 114 is any other metadata that might be associated with any of the components of the environment. 115 is the application data (e.g. client session, user input data, cookies, local storage, application related variables etc. ). 210 is an equivalent application running in 200. 220 is the Runtime Component that helps to achieve the desired outcome proposed in the invention (might be part of the OS). 200 is connected to the internet via port 240. 150 is a means of connection (e.g. wifi, LAN, Bluetooth, NFC, IR etc. ) of 100 with any other devices like in this case 200. 250 is the similar means of connection. Both 100 and 200 are connected to each other - for which may 100 might be using any other port 130 and same for 200 where it might be using 230. Now when the user runs device 100 and runs application 110, his data related to that state is collected and transferred to the other device 200 over the connection. This transfer is depicted as 160. This data is stored by the runtime 220 as 111, 112, 113, 114, 115. Now runtime selects the compatible application 210 which may have it's own session 211 and other related data. Now runtime 220 uses 111, 112, 113, 114, 115 to determine what can be populated in 210 , which may include the text or any info the user had entered in device 100 and this allows to run the application 210 with the user's data. Now the user uses device 200 to continue using editing or working on his data using app 210 and once he finishes, runtime 220 collects the modified data from the app 210 and sends it back to device 100 , depicted in 260 so that in 100 the runtime 120 uses that to populate the app 110 and within the same session as 111 and if the need is to update some server over the internet, it can do so via using the same session and thread via the same network port as 140. Note : The above example shows only a generic approach and describes the overall components. Depending on the scenario the usage might vary slightly -- for example if the user does not need to use same session and the port to connect to server, the flow might be different where once the user has updated his info in 210 on device 200, instead of sending back the updated data to device 100 as depicted in 260, the 220 runtimes can submit it to server or backend using 240 over a different session.
